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Introduction 

TTiis document provides the inicrface for the 32-Bit BIOS Power Management Service Interface fBPMM^ 
interface .s used by the Windows NT Power Management Kernel driver or pTvtdiie SwVr " 
management services to APM-awarc applications. providing power 

Terms 

APM BIOS 

«^sion le° I ^2)^ management functions adhering to the APM specification (currently at 

Kernel Mode 

^nrcwi!!^*** processor mode in which the NT systenn code runs. A kernel mode thread has access to all 1/0 

ana sysicm memory 

Power Management Kernel Driver (PM Driver) 
Provides access to the BIOS ROM. BIOS Data Area and the 32-Bit Services for Services. 

Power Management Service (PM Service) 

Provides power management services for applications and other drivers. Translates their requests into 
queries to the BIOS Power Management Service Interface usinc the interface provided by the Power 
Management Kernel Driver (PM Driver). " 

PowerPAL 

Phoenix s APM BIOS extensions which provide application level access to system and device power 
management features 

System Idle 

State where PM service detected minimum processing at the application level. In this sute. only threads run 
on Idle priority are executed arid ihey will be preempted by any thread ninning in a higher priority class. 

User Mode 

A non-pnvilcged processor mode in which application code nins. An user-mode thread does not have 
access to I/O and system memory. 
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Architecture Overview 

■nic extensions to the BIOS for support of Windows power management consist of two parts: 

n^ttl' ''"^®^°."o.?.rn'" ^" '^'^'^ -hich allows the PM Dover ,o 

^u. ^ 5^ « P*""' Management Service Interface. 

dilflen;« wh°r°**' Management Service, which mimics the APM 32-bit interface with some 
«/urT,tH bebw. TTie new interface provides a 0:32 calling method which is more 

secure and more Wmdows NT friendly. 

When the PM Kernel wishes to use the BIOS services, it must perform the following steps: 

1 . Find the BIOS32 Service Directory header 

2. Call the B10S32 Service Directory calling interface, specifying the 32-Bil BIOS Power Management 
service Interface entry point. 

^" ConnMi^'°^ Management Service Interface entry point, asking for APM 

BIOS32 Service Directory IVIodlficatlons 

The 32-bit BIOS Service Directory is an existing stnicturt within the Phoenix BIOS which allows a 32-bii 
protected mode application or operating system to find the enay point for a particular 32-bit service TTiis 
specification defines a new standard 32-bit BIOS Service. 

The BIOS32 Service Directory consists of a fixed strocture which can be detected by the PM driver and a 
single function which returns the address for a particular service. 



The BIOS32 Service Directory Header 

A BIOS which implements the BIOS32 Service Directory must embed a speciHc. contiguous 16-byte 
pattern somewhere in the physical address range OEOOOOh - OFFFFFh. The pattern must be paragraph 
Header " * boundary). TTiis pattern is known as the BIOS32 Service Directory 

The Header is comprised of six distinct fields. The following uble describes each field. 
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4 bytes j Th e ASCII signature ".32_'' or Ox5F3332SF 

4 bytes I The entry point for ihe BIOS32 Service Directory calling interface. This is a 32-bii 

! linear (i.e., not segmentrofTset) physical address 

I byte j TTic revision level of the BIOS32 Service Directory header and calling interface. The 
curreni revision is 0. 



1 byte 



The length of the BIOS32 Service Directory header. Measured in paragraphs (16 
bytes). The current lenph is 1. 



10 

TT 



1 byte 



The BIOS32 Service Directory header byte-wide, byte-sum checksum. When loialcd, 
' all of the bytes in the header should ad up to 0. ' 



5 bytes ' Reserved. Should be 0. 



Clients of the BIOS32 Service Direct ory should first determine its existence by locating the Header. This is 
done by scanning OEOOOOh to OFFFFOh in paragraph incrcmcnis and looking for a signature match C 32 -) 
m the first 4 bytes of each paragraph. When, and if, the signature is detected the client should perform" a " 
checksum of all bytes in the Header. (The Header length, in paragraphs, is found at offset 9h.) All bytes in 
the Header should ADD together with a result of Oh, If the checksum is valid then the 32-bii entry point 
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field can be used as the address for the BIOS32 Service Directory CalHt^g Inicrfacc, If the Header is not 
found then the BIOS32 Service Dircciory does not exist on the platform. 

The BIOS 32 Service Directory entry point, and its associated code and data, maybe located anywhere 
within the 4Gb physical address space. However, it is guaranteed to be physically contiguous (i.e., it will be 
delivered in ROM or FLASH space) and to fit within two pages (i.e., it will not span three pages). 



The BIOS Service Directory 

To gel the entry point to the BIOS 32-Bit Power Management Service Interface, the PM Driver must call 
the BIOS Service Directory with the following parameters: 

IN: EAX '*NTPM"orOx4E54504D 

EBX 0x00000000 

OUT: AL Error code: 0x00 = None, 0x81 = Service docs not exist 

EBX Base address of the 32-Bit Power Management Service code 

ECX Length of the 32-bit Power Management Service code (from EBX) 

EDX Offset (from EBX) of the 32-bil Power Management Service code entry point 

The entry point of the 32-bit Power Management Service code entry point is FAR (that is, 
requiring both segment and offset to be pushed on the stack.) 

CS: The base address must be less than or equal to the (4KB) page address of the page that contains the 
entry point. For example, if the entry point i$ 0FFF81234h, then the base addrcu must be less than 
or equal to 0FFF8 lOOOh. The limit must be such thai the base address plus the limit generate an 
address that is greater than or equal to the last address on the (4KB) page which follows the page 
conuining the entry point For example, if the entry p oint is 0FFF8l234h then the base address 
plus the limit must be greater than or equal to 0FFF82FFFh. Simply suted, the base address and 
the limit must "encompass" both the page that contains the entry point and the following page. 

The segment type must be I0(fc (code, execute only) or 101b (code, execute/read). However, the 
implementcrs of the Service Directory cannot assume read access to the CIS code segment The 
system bit must be 1 (non-system segment). It is recommended that the Descriptor Privilege Level 
(DPL) be 0, (The CS descriptor DPL becomes the Current Privilege Level, or CPL). If the GPL is 
not 0, then the OS must provide trapping and virtualizaiion services for ring 0 privileged 
instructions (such as those that access CRx), Note also the dependency of this field on the lOPL 
Held in EFLAGS (see SectionO). 

The Default Size bit must be 1 (32 bits). 

DS: The base address must be equal to the CS base address. The limit must be greater than or equal to 
the CS limit 

The segment type must be OOOb (data, read only) or 001 (data, readAimte). However, the 
implementcrs of the Service Directory cannot assume write access to the DS data segment. The 
system bit must be 1 (non-system segment). The Descriptor Privilege Uvel (DPL) must be greater 
than or equal to CPL (see the DPL field in Section 0). 
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The segment lypc must be 01 lb (data, rtad/writc. expand-down) or OOlb data, rcad/wriie. expand- 
up). The system bit must be 1 (non-system segment). The E>escriptor Privilege Level (DPL) must 
be equal to the CPL (sec the DPL Held in Section 0). The Default Size bit must be 1 (32 bits) The 
Granularity bit must be 1 (4Kb). 

Note thai the above settings ensure a stack size of at least 4kb. It is the caller's responsibility to 
ensure that there is at least Ikb of unused suck available. 

Paging: Paging may or may not be enabled. If paging is enabled, then the address space that is described by 
the CS and DS selectors must be linearly contiguous. That is, the original physical contiguity of the 
Calling Interface as found in ROM or FLASH must be preserved. (The Calling Interface code and 
data is written to be position-indcpendent and ElP-relaiive). 

lOPL: In order for the Calling Interface to execute I/O instructions, the I/O Privilege Level (lOPL) field 
in EFLAGS must be greater than or equal to the CPL (sec the DPL field in Section 0). 

Other: The BIOS Data Area, Extended BIOS Dau Area and fixed-location ROM data ubles cannot be 
assumed to be available for use by the executing code because of paging. The BD A may be 
accessed using the pointer provided by the caller. 



32-Bit BIOS Power Management Service Interface 

In general, the 32-Bii BIOS Power Management Interface provides the same functionality as the 32-bii 
APM entry point. There are two areas of difference: the way in which calling parameters are passed and the 
way in which certain APM connect functions arc supported. 



Calling Parameters 

The APM 32-Bit Interface passes all parameters in CPU registers. The BIOS Power Management Service 
Interface passes the parameters on the stack. The equivalent C-style declaration would be: 

typedef struct 

( 



ULONG 


reservedO ; 


/♦ 


00 


*/ 


ULONG 


pBDA; 


/* 


04 


•/ 


ULONG 


regPlags; 


/• 


08 


♦/ 


ULONG 


reservedl ; 


/* 


OC 


•/ 


ULONG 


reserved2; 


/• 


10 


•/ 


ULONG 


reservedS ; 


/* 


14 


•/ 


ULONG 


reserved4 ; 


/* 


18 


*/ 


ULONG 


reservedS ; 


/♦ 


IC 


•/ 


ULONG 


reserved6 ; 


/• 


20 


•/ 


ULONG 


reserved? ; 


/* 


24 


♦/ 


ULONG 


reservedS; 


/• 


28 


•/ 


ULONG 


reserved9; 


/* 


2C 


•/ 


ULONG 


regEBP; 


/* 


30 


•/ 


ULONG 


regEDI ; 


/* 


34 


•/ 


ULONG 


regESI ; 


/♦ 


38 


V 


ULONG 


regEDX; 


/* 


3C 


•/ 


ULONG 


regECX; 


/♦ 


40 


•/ 


ULONG 


regEBX; 


/• 


44 


*/ 


ULONG 


regEAX; 


/• 


48 


•/ 



} regStruct; 
unsigned char BPMSI ( regStruct* parameters); 
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The actual APM function and its behavior will be dciermincd by the value written in the corresponding 
rcgtsicr fields. The pBDA field is a pointer to the virtual address where the kernel driver has mapped the 
BIOS Data Area so that it can be accessed by the service entrance. 

If an error occurs, bit 0 of regFlags will be 1 and the error code will be in bits 8-15 of regEAX, otherwise ii 
will be 0 and bits 8-15 of regEAX will be 0. The error codes are identical lo those found in the APM 1 2 
specification. 
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Software Requirements 
Development Software Requirements 

The following software development tools are required to build the PM service: 

• M ASM 6.11c assembler from Microsoft 

• Phoenix PhDebug for debugging the code 



Software Requirements 

PM service requires to nin on the following environment: 

• Windows NT 4.0 

• System with Phoenix NoteBIOS suppoiting the NT BIOS Interface to the PowerPAL 

• PM driver installed in the system 



Porting Changes 

Tht following section describes the files which have been modified in the Core. Miser and the chipset code 
It also describes the changes which need to be made in order to port a normal BIOS to include the NT 
suppon. 
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